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C . REMARKS 

Examiner Interview 

Applicant wishes to thank the Examiner and his supervisor 
for the courtesy extended to Applicant's attorney during the 
telephone interview of November 17, 2004. 

Drawings 

Applicant notes with appreciation the acceptance of 
Applicant's formal drawings by the Examiner in the Office 
Action. 

Amendments to the Specification 

The specification has been amended to correct an 
inadvertent typographical error, and also to add serial numbers 
and filing dates of the related applications. 

Status of the Claims 

Claims 1, 2, 5, 6, 8-11, 13, 14, 17, 18, and 20 have been 
amended. Claims 4 and 16 have been cancelled. Claims 1-3, 5- 
15, and 17-20 are currently present in the Application, and 
claims 1, 9, and 13 are independent claims. 

Claims 1-3, 5, 8, 13-14, and 20 stand rejected under 35 
U.S.C. § 102(b) as being anticipated by Berson, U.S. Patent No. 
5,598,477 (hereinafter Berson). Claims 4-6, 9-11, and 16-18 
stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Berson in view of Sansone, U.S. Patent No. 6,454,174 
(hereinafter Sansone). Claims 7 and 19 stand rejected under 35 
U.S.C. § 103(a) as being unpatentable over Berson and Sansone in 
view of Bruce Schneier's Applied Cryptography (hereinafter 
Schneier). Claim 12 also stands rejected under 35 U.S.C. § 
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103(a) as being unpatentable over Berson and Sansone in view of 
Schneier. Applicant respectfully traverses the rejections. 

Claim Rejections - Alleged Anticipation Under 35 U.S.C. § 102 

Claims 1-3, 5, 8, 13-14, and 20 stand rejected under 35 
U.S.C. § 102(b) as being anticipated by Berson. Applicant 
teaches and claims a method, system, and computer program 
product for processing tickets that include customer security 
features. Independent claims 1 and 13 (and similarly, 

independent claim 9) have been amended to clarify that customer 
security features are used to "identify a customer associated 
with the ticket." The use of security features to identify a 
particular customer is discussed in detail in Applicant's 
specification, including, e.g., on page 4, lines 2-10; page 9, 
lines 19-26; page 11, lines 12-14; and page 12, lines 16-19. 
Also note that independent claims 1 and 13 have been amended to 
include the limitations previously found in dependent claims 4 
and 16, respectively. These elements are addressed more fully 
below with regard to the claim rejections under 35 U.S.C. § 103. 

Berson purports to teach a system and method for issuing 
and validating tickets (see Abstract). However, Berson does not 
teach or suggest the elements of Applicant's independent claims. 
Specifically, Berson does not teach or suggest "receiving a 
ticket from a ticket holder" that includes "one or more customer 
security features, wherein the customer security features 
identify a customer associated with the ticket" (emphasis 
added) . Rather, Berson is concerned with validating the ticket 
itself, not the ticket holder. Berson states that "preferably 
information T will include sufficient information to enable 
automatic reconciliation of ticket 22 (col. 3, lines 63-65, 
emphasis added). Berson further goes on to state that "the 
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encrypted validating information preferably will include enough 
of the conventional information to allow automated 
reconciliation of the ticket when the ticket is scanned." (col. 
4, lines 62-65 ,' emphasis added). 

A close reading of Berson finds absolutely no mention of 
customer security features that "identify a customer associated 
with the ticket" as taught and claimed by Applicant in amended, 
independent claims 1, 9, and 13. Although Berson does mention 
digital signatures, the digital signatures in Berson are not 
intended to "identify a customer associated with the ticket" as 
taught and claimed by Applicant. Berson states the following 
with regard to digital signatures: 



Preferably field 22BC includes information T which 
corresponds to at least a part of the conventional ticket 
information printed in field 22T, and preferably 
information T will include sufficient information to enable 
automatic reconciliation of ticket 22, as will be described 
further below. Information T may either be fully encrypted 
or, preferably, may be digitally signed. As is well known 
to those skilled in the art information is digitally signed 
by extracting a portion of the information, such as a check 
sum, and encrypting the extracted information. The signed 
information is then validated by repeating the process and 
comparing the digital signatures. In an althernative 
embodiment of the invention field 22BC can contain only a 
signature of the conventional information in field 22T and 
information to reconcile ticket 22 can be recovered by 
optical character recognition (OCR) techniques or an 
operator, if desired. (col. 3, line 61 through col. 4, 
line 9, emphasis added). 

Berson is concerned with reconciliation of the physical 
ticket itself, and not with identifying the customer of the 
ticket. Berson uses either a digital signature or a signature 
of the ticket information to verify that the ticket itself is a 
valid, i.e. not forged, ticket. Berson reconciles the physical 
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ticket, but does not teach or suggest customer security features 
that identify a customer associated with the ticket, as taught 
and claimed by Applicant. 

Because Berson does not teach or suggest customer security 
features that identify a customer associated with the ticket, 
Berson also does not teach or suggest "comparing the stored 
customer security features to the ticket holder and to the 
customer security features included on the ticket," or 
"accepting the ticket in response to the stored customer 
security features matching the ticket holder and the customer 
security features included on the ticket," as taught and claimed 
by Applicant in amended, independent claims 1 and 13 (and 
similarly, amended, independent claim 9). There is no 

disclosure in Berson of determining whether the ticket holder, 

1. e. the customer presenting the ticket, matches any customer 
security features. In the sections of Berson cited by the 
Examiner, i.e. col. 4, lines 10-18 and col. 5, lines 20-25, the 
barcode information is decrypted and compared to test 
information T in order to determine if the ticket is a valid 
ticket. Decrypted information T is compared to the information 
printed on the ticket in order to determine if the ticket has 
been forged, not in order to determine if the ticket holder 
himself or herself matches the customer security features. In 
Berson, if the physical ticket is validated, Berson then prints 
boarding passes, luggage checks, etc. (col. 5, lines 26-28), 
without any regard for whether or not the ticket holder matches 
any customer security features. 

Berson is concerned with validating a physical ticket (col. 

2, lines 3-17), and does not teach or suggest Applicant's 
claimed method, system, and computer program product for 
processing tickets that include customer security features that 
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identify a customer associated with a ticket. Therefore, 
Applicant respectfully submits that independent claims 1 and 13, 
and the claims which depend from them, are patentable over 
Berson. 

Claim Rejections - Alleged Obviousness Under 35 U.S.C. § 103 

Claims 4-6, 9-11, and 16-18 stand rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over Berson in view of Sansone. 
Note that independent claims 1 and 13 have been amended to 
include the limitations previously found in dependent claims 4 
and 16, respectively, and also to clarify that the stored 
customer security features are checked against both the ticket 
holder himself or herself, and the customer security features 
included on the ticket. Independent claim 9 has also been 
amended to make this clarification. 

As discussed above, Berson does not teach or suggest key 
elements of Applicant's independent claims. Sansone does not 
overcome the deficiencies of Berson. Sansone purports to teach 
an electronic ticket containing "information about the personal 
computer that printed the ticket" (col. 1, line 66 through col. 
2, line 1). Sansone discloses two bar code, bar code 20 and bar 
code 63 (col. 2, lines 34-49). Bar code 63 "represents the 
printer settings (printer manufacturer, model no., resolution, 
density, etc.) of the printer that printed ticket 11" (col. 2, 
lines 44-47 ). Bar code 20 "contains in coded form the name of 
the place of the event 17, the address of the event 18, and a 
unique number 19" (col. 2, lines 49-54). Sansone goes on to 
disclose that "[b]ar code 63 and number 64 may also be used to 
validate the printer that prints ticket IV (col. 2, lines 52- 
54, emphasis added). 
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Sansone is concerned with preventing people from printing 
fraudulent tickets (col. 1, lines 25-27; col. 1, lines 38-50). 
Sansone does not teach or suggest tickets containing customer 
security features where "the customer security features identify 
a customer associated with the ticket" as taught and claimed by 
Applicant. Because Sansone does not teach or suggest customer 
security features that identify a customer associated with a 
ticket, Sansone can not teach or suggest "retrieving one or more 
stored customer security features corresponding to the ticket 
identifier in response to the scanning," "comparing the stored 
customer security features to the ticket holder and to the 
customer security features included on the ticket," or 
"accepting the ticket in response to the stored customer 
security features matching the ticket holder and the customer 
security features included on the ticket" as taught and claimed 
by Applicant in independent claims 1, 9, and 13 

In the portions of Sansone cited by the Examiner, 
specifically column 7, lines 22-30, Sansone discloses 
determining whether the information from bar codes 63 and 2 0 is 
the same as the information stored in archive 66 (col. 7, lines 
22-27). Sansone states that bar code 63 "represents the printer 
settings (printer manufacturer, model no., resolution, density, 
etc.) of the printer that printed ticket 11" (col. 2, lines 44- 
47). Sansone further defines bar code 20 as containing "in 
coded form the name of the place of the event 17, the address of 
the event 18, and a unique number 19" (col. 2, lines 49-54). 
Unique number 19 is defined to "represent a computer record" 
(col. 2, lines 40-41). Other than this reference to unique 
number 19, no further detail is given in Sansone regarding the 
use of unique number 19 or the computer record it purports to 
represent. Archive 66 is an image data archive (col. 3, lines 
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65-67; also see Sansone Figure 5) that stores images of issued 
tickets (col. 4, lines 5-7). Thus, Sansone discloses comparing 
the information in bar codes 63 and 20, i.e. the printer 
settings of the printer that printed the ticket and the name and 
address of the place of the event, to a stored image of the 
ticket in order to determine if the physical ticket is or is not 
a forgery. There is no teaching or suggestion in Sansone 
regarding determining whether "stored customer security 
features" match "the ticket holder and customer security 
features included on the ticket," where "customer security 
features identify a customer associated with a ticket" as taught 
and claimed by Applicant in independent claims 1, 9, and 13. In 
addition, the ticket shown in Figure 1 of Sansone does not show 
any "customer security features" that "identify a customer 
associated with a ticket." The ticket illustrated in Figure 1 
of Sansone does not even include the customer's name, much less 
any features that would assist in identifying a customer 
associated with the ticket. 

With regard to claims 5, 10, and 17, Sansone does not teach 
or suggest "sending a request to a security server, the request 
including a customer identifier that uniquely identifies the 
customer of the ticket," as taught and claimed by Applicant. 
The Examiner cites item 20 in Sansone as being analogous to a 
customer identifier. However, as discussed above, Sansone 
defines item 20 as being a bar code (col. 2, line 41) that 
contains "in coded form the name of the place of the event 17, 
the address of the event 18, and a unique number 19" (col. 2, 
lines 49-54) . Unique number 19 is defined to "represent a 
computer record" (col. 2, lines 40-41). Other than this 
reference to unique number 19, no further detail is given in 
Sansone regarding the use of unique number 19 or the computer 
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record it purports to represent. However, it is clear that 
nothing in bar code 20 has anything to do with VN a customer 
identifier that uniquely identifies the customer of the ticket" 

as taught and claimed by Applicant. 

With regard to claims 6, 11, and 18 Sansone does not teach 
or suggest "sending a merchant identifier to the security 
server, the merchant identifier uniquely identifying a merchant " 
as taught and claimed by Applicant. The Examiner cites the 
venue data in Sansone as being analogous to a merchant 
identifier, however, Applicant respectfully disagrees. Venue 
data would presumably include data regarding the name and 
location where an event is being held, but may not necessarily 
indicate who, i.e. which merchant, sold the ticket to a 
customer. Further, Sansone does not teach or suggest that "the 
receiving of the stored security features is performed in 
response to the merchant identifier being authorized by the 
security server" as taught and claimed by Applicant. The 
portion of Sansone cited by the Examiner, i.e. col. 7, lines 17- 
21, merely discuss sending information to a data center upon 
determining that a ticket is valid. There is no disclosure 
related to authorizing a merchant identifier. 

Claims 7, 12, and 19 stand rejected under 35 U.S.C. § 
103(a) as being unpatentable over Berson and Sansone in view of 
Schneier. Applicant notes that Applicant is not relying solely 
on the use of a digital signature as the basis for patentability 
of Applicant's claims. Schneier does not overcome the 

deficiencies of Berson and Sanson. 

For the reasons set forth above, Applicant respectfully 
submits that independent claims 1, 9, and 13, and the claims 
that depend from them are patentable, and respectfully request 
that they be allowed. 
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Conclusion 

As a result of the foregoing, it is asserted by Applicant 
that the remaining claims in the Application are in condition 
for allowance, and Applicant respectfully requests an early 
allowance of such claims. 

Applicant respectfully request that the Examiner contact 
the Applicant's attorney listed below if the Examiner believes 
that such a discussion would be helpful in resolving any 
remaining questions or issues related to this Application. 

Respectfully submitted 

Leslie A. Van Leeuwen, Reg. No. 42,196 
Joseph T. Van Leeuwen, Reg. No. 44,383 
Van Leeuwen & Van Leeuwen 
Attorneys for Applicant 
Telephone: (512) 301-6738 
Facsimile: (512) 301-6742 
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